home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP022392.ARJ / 02-23-92.TPC
Text File  |  1992-02-23  |  53KB  |  1,506 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       02-16-92 02:19:00
  6. From       Trevor Carlsen
  7. To         Thomas Stein
  8. Subject    DB-Dateien
  9.  
  10.  TCID:6dbfc7f3 58b2
  11. TS> Du schriebst in der PASCAL-Conference:
  12.  
  13. The rules for this conference require that all messages are in English.
  14. FidoNet also requires that no "hi-bit" characters are used and I notice that
  15. you have hi-bit characters in your tear line (quite apart from those in the
  16. message text due
  17. to your language).
  18.  
  19. Trevor Carlsen
  20. Moderator.
  21.  
  22. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  23.  
  24.  
  25. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  26.  
  27. Conference 4
  28. Date       02-16-92 02:28:50
  29. From       Trevor Carlsen
  30. To         Kelly Small
  31. Subject    Menu Files
  32.  
  33.  TCID:66d99e24 58b3
  34. CA > Begin
  35. CA > Assign(MnuFile, 'MainMenu.Mnu');
  36. CA > {$I-} Reset(MnuFile);
  37. CA > If IoResult > 0 Then
  38. CA > Trouble('Opening Mainmenu.Mnu!');{Just A File Error Routine}
  39. CA > {$I+}
  40. CA > Read(MnuFile, menu);
  41. CA > Close(MnuFIle);
  42.  
  43. KS> You are trying to read a fixed record format as though it was
  44. KS> text...
  45.  
  46. Kelly, I have read many of your posts and they are usually very correct.
  47. This one is in error however.  The above code has absolutely nothing wrong
  48. with it if the writer intends to read only the first record.  It is most
  49. certainly NOT being
  50. read as a text file.
  51.  
  52. KS> ... Replace the read statement with:
  53.  
  54. KS> Reset(Mnufile,1);
  55. KS> Blockread(MnuFile,Menu,Sizeof(Menu));
  56. KS> Close(MnuFile);
  57.  
  58. This would not compile because Mnufile has been declared as a typed file.
  59. Now even if it was changed to make it compilable, all that does is exactly
  60. what was being done in the original - read the first record into Menu.
  61.  
  62. TeeCee
  63.  
  64. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  65.  
  66.  
  67. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  68.  
  69. Conference 4
  70. Date       02-16-92 02:36:50
  71. From       Trevor Carlsen
  72. To         Jim Esten
  73. Subject    Text File Snag
  74.  
  75.  TCID:ca50c946 58b4
  76. JE> ... I'm writing a parser that takes an ascii text file from
  77. JE> an electronic payroll time clock and rewriting the strings
  78. JE> to the format required by various payroll software packages.
  79. JE> Problem - one of the clocks I work with generates an ascii
  80. JE> file the has a header (no problem, I read it prior to the
  81. JE> loop), the individual employee records with Id numbers,
  82. JE> names, hours., etc (no problem), but then has a blank line
  83. JE> before a totals line.  I've tried EOF and EOLN but both hang
  84. JE> at the blank line.  Am I resigned to have the end user input
  85. JE> the number of records to stop the loop prior to the blank
  86. JE> line?
  87.  
  88. I'd like to see the routine you are using to read the text file.  However
  89. if it is much different to this then perhaps give this a try...(As a last
  90. resort you could try BlockRead by opening the file as an untyped file but
  91. that then gets messy
  92. with parsing the strings etc)...
  93.  
  94.  var
  95.    inpstr : string;
  96.    len    : byte absolute inpstr;
  97.  
  98.  while not eof(f) do begin
  99.    len := 0;
  100.    while (not eoln(f)) and (len < 255) do begin
  101.      inc(len);
  102.      read(f,inpstr[len]);
  103.    end;  { while (not eoln(f))... }
  104.    if eoln(f) then
  105.      readln(f);
  106.    Do what you want with the string here.
  107.  end; { while not eof(f) }
  108.  
  109. However the above is unnecessary if you know that no string is longer than
  110. 255 characters and that the lines are properly delimited with CRs. Then you
  111. can do normal Readln()s.
  112.  
  113. To be sure of solving your problem we would need to see your code.
  114.  
  115. TeeCee
  116.  
  117. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  118.  
  119.  
  120. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  121.  
  122. Conference 4
  123. Date       02-16-92 02:51:00
  124. From       Trevor Carlsen
  125. To         John Richardson
  126. Subject    INTR VERSUS BASM
  127.  
  128.  TCID:533ec715 58b5
  129. JR> I don't beleive that Turbo Pascal v6.0 uses real interrupt calls...
  130.  
  131. I have the RTL and I can assure you that TP6 certainly makes "real interrupt
  132. calls"
  133.  
  134. TeeCee
  135.  
  136. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  137.  
  138.  
  139. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  140.  
  141. Conference 4
  142. Date       02-16-92 02:55:20
  143. From       Trevor Carlsen
  144. To         Richard Van Fossan
  145. Subject    Tp 5.5 Vs Tp 6.0
  146.  
  147.  TCID:b44b6aad 58b6
  148. RVF> Russell: Something I'm hoping to be able to work with soon
  149. RVF> is C++ under OS/2 version 2.0. I've been privelaged to have
  150. RVF> an evaluation copy of OS/2 v2.0; the public release date is
  151. RVF> in March, I think. It's a dream to work with (if you forgive
  152. RVF> a few bugs and lags inherent in beta-release code), and I'd
  153. RVF> love to do some heavy-duty C++ objects in OS/2 (32-bit
  154. RVF> code).
  155.  
  156. This appears to have no bearing on the subject line and is definitely off-topic.Please take the discussion to netmail or the C echo.
  157.  
  158. Trevor Carlsen
  159. Moderator.
  160.  
  161. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  162.  
  163.  
  164. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  165.  
  166. Conference 4
  167. Date       02-17-92 15:43:50
  168. From       Trevor Carlsen
  169. To         Kiev Lo
  170. Subject    Re: Tp 6.0
  171.  
  172.  TCID:b20a9edb 5936
  173. MC>   2. TurboVision, a simplified application development
  174. MC> interface (for screens and windows and such. This appears
  175. MC> to be created for newer TP programmers who haven't used
  176. MC> after-market libraries, such as TPro, TechnoJocks Turbo
  177. MC> Toolkit, or Eagle. It's a new way of doing things many of
  178. MC> us already have "in hand", IMO.
  179.  
  180. KL> So, is TV any better than any of the "after-market
  181. KL> libraries"?  I've been using TechnoJocks Turbo Tookit and I
  182. KL> found it excellent.
  183.  
  184. As far as I'm concerned TV doesn't have any competitor or real equivalent
  185. in the market place.  The closest would be OPro, but even that is really
  186. aimed at a different philosophy.  TV does a different job to OPro and so
  187. the two cannot be legitimately
  188. compared.  Both are brilliantly successful in achieving their design aims.
  189. TTT and TV are really unrelated in what they set out to achieve.
  190.  
  191. I suppose that I am really saying that I disagree with Mike's assessment
  192. of TV and what TV is and does.  It is most certainly NOT for newer TP programmerin fact I consider that it is closer to the mark to say the reverse.  I say
  193. all this
  194. knowing that many in this echo are thinking "that isn't what he said 12
  195. months ago", and they are right... I have changed my opinion, largely due
  196. to the prodding of others whose opinions I respect very much.
  197.  
  198.  
  199. TeeCee
  200.  
  201. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  202.  
  203.  
  204. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  205.  
  206. Conference 4
  207. Date       02-17-92 16:03:20
  208. From       Trevor Carlsen
  209. To         Ken Koch
  210. Subject    Compress on data
  211.  
  212.  TCID:97c91ea5 5937
  213. KK> The record not only consists of those 5 strings but 10 bytes for
  214. KK> centering & mode control, and a 501 byte graphic image.
  215.  
  216. The centering and mode control - is it the same for every label?  What about
  217. the graphical image is it the same for every label or different.  If different,
  218. in what way is it different?
  219.  
  220. TeeCee
  221.  
  222. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  223.  
  224.  
  225. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  226.  
  227. Conference 4
  228. Date       02-18-92 02:53:30
  229. From       Trevor Carlsen
  230. To         Mike Hindle
  231. Subject    Variable number of parameters
  232.  
  233.  TCID:29f451e2 5976
  234. MH> have you in your travels come across a simple (or even complex) way
  235. of
  236. MH> allowing a variable number of parameters for a procedure? I am
  237. MH> assuming that
  238. MH> it is possible as many of the TP procedures allow it. Ie Write().
  239.  
  240. The compiler parses write/writeln/read/readln and all the other procedures
  241. that permit a variable number of parameters at compile time.  What you are
  242. trying for is something for runtime - quite a different thing.  Not possible
  243. without kludges
  244. such as passing a pointer to a linked list of variables which can then be
  245. traversed and processed.
  246.  
  247. I suggest a rethink is in order as a simple reassessment of your design philosopshould be all that is required.  Why not post the details of your problem?
  248.  
  249. TeeCee
  250.  
  251.  
  252. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  253.  
  254.  
  255. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  256.  
  257. Conference 4
  258. Date       02-18-92 01:42:40
  259. From       Trevor Carlsen
  260. To         Chris Whitney
  261. Subject    TP6 is screwy! HELP!!
  262.  
  263.  TCID:abac81fc 5977
  264. CW>   HELP!!  Turbo Pascal 6.0 is screwed up!  It keeps changing variables
  265. CW> to large negative numbers for no reason!  It happens only once and a
  266. CW> while being played, but when it does it really messes things up!
  267.  
  268. Make sure you turn on range checking {$R+} and see what happens.
  269.  
  270. Also check that you are not being affected by integer wrap.  eg.
  271.  
  272.  var
  273.     i,j : integer;
  274.  
  275.  i := 20000; j := 2;
  276.  i := i * j / j;
  277.  
  278. will produce 14464.  This is because of integer wrap.
  279.  
  280. With the for loop check that you are doing anything to change the value of
  281. the loop while in the loop.  You say you are using a multi-dimensioned array.
  282. Such structures are prime candidates for out-of-range problems overwriting
  283. other variables
  284. because any range error can affect locations so far from their own.
  285.  
  286. Wild pointers are another possibilty.  You really need to be watching what
  287. happens in the debugger.
  288.  
  289. TeeCee
  290.  
  291. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  292.  
  293.  
  294. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  295.  
  296. Conference 4
  297. Date       02-18-92 01:48:40
  298. From       Trevor Carlsen
  299. To         Kevin Higgins
  300. Subject    Completely Stumped!
  301.  
  302.  TCID:1194d6ac 5978
  303. > Do you have range and stack checking enabled?  Earlier parts of
  304. > your code might be causing the fatal problem.
  305.  
  306. KH>     Yep, I've tried that, too, and it STILL does it. Next idea?
  307.  
  308. Place a watch on ExitProc and see what happens.  If that does not show anything
  309. you need to start checking out interrupt vectors.  Try and shorten your code
  310. to an example that demonstrates the problem and post it here.
  311.  
  312. TeeCee
  313.  
  314. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  315.  
  316.  
  317. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  318.  
  319. Conference 4
  320. Date       02-18-92 02:56:30
  321. From       Trevor Carlsen
  322. To         Kevin Higgins
  323. Subject    Still looking...
  324.  
  325.  TCID:513f63fa 597a
  326. KH> For a program called ACODES. Actually, I'd like to see any routines
  327.  
  328. KH> that can be used to encode or otherwise protect a program's data files
  329.  
  330. KH> from (easy, at least) hacking. Routines should not only encode the
  331. KH> data, but should check to ensure that the data has not been modified
  332.  
  333. KH> since last written....
  334.  
  335. Here is a simple routine that will encode or decode a variable.  All that
  336. needs to be done is call the routine with either a 4 character password (or
  337. better still a 4 byte longint value) and the variable will be coded using
  338. a very simple algorithm.
  339.  To decode do it again.  If you forget your password or key you will have
  340. a very difficult - almost impossible job to decode it.
  341.  
  342. The routine also requires that you pass the size of the data for coding/decodingA too-high value here will cause disaster so best to pass it as sizeof(TheData)In other words the same caveats as move/fillchar/BlockRead etc.
  343.  
  344. This is not suitable for text files as the resulting coded data may contain
  345. control codes.
  346.  
  347. procedure code(var d,k; len: word);
  348.  { Uses a very simple algorithm to encode d }
  349.  const
  350.    maxsize = 1024;
  351.  var
  352.    data  : array[1..maxsize] of byte absolute d;
  353.    key   : longint absolute k;
  354.    Bkey  : byte;
  355.    x     : word;
  356.  begin
  357.    if len > maxsize then { ensure that length of data is within limits }
  358.      exit;               { or leave procedure without doing any damage }
  359.    RandSeed := key;
  360.    for x := 1 to len do begin
  361.      Bkey := random(256);
  362.      data[x] := data[x] xor Bkey;
  363.    end;
  364.  end;  { code }
  365.  
  366. TeeCee
  367.  
  368. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  369.  
  370.  
  371. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  372.  
  373. Conference 4
  374. Date       02-18-92 20:37:00
  375. From       Werner Berghofer
  376. To         Felix v Leitner
  377. Subject    Your bug or mine?
  378.  
  379.        Felix,
  380.  
  381. > Turbo Pascal's close(t) for var t : text; appends
  382. > a ^Z character to the file [...]
  383.  
  384.       sorry, that's not true.
  385.  
  386.       W.
  387.  
  388. * Origin: God is real... unless declared integer. (2:310/90.100)
  389.  
  390.  
  391. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  392.  
  393. Conference 4
  394. Date       02-19-92 01:32:10
  395. From       Trevor Carlsen
  396. To         Kevin Higgins
  397. Subject    Completely Stumped!
  398.  
  399.  TCID:11946aa6 59be
  400. KH> Can anyone explain to me what I could possibly be doing wrong in a
  401. KH> program where a Halt(0) statement locks up the system completely?
  402.  
  403. > Without being able to see your code
  404. KH>      The code is to a large program. Could not do it here!
  405.  
  406. Fair enough.
  407.  
  408. > this problem has the symptoms of that most dangerous of
  409. > errors - failing to unhook hooked vectors before exitting a
  410. > program. Are you hooking any vectors within your code?
  411.  
  412. KH>      Not to my knowledge. The only reference I could find to vectors
  413.  
  414. KH> was in the swapping of them prior to and after executing an Exec()
  415. KH> procedure; I'm not using any of those... How else might I hook a
  416. KH> vector, and why would I do so?
  417.  
  418. If you didn't deliberately hook any, then there shouldn't be any hooked.
  419. However you now need to start looking closely at how you are getting memory
  420. trashed, as that is almost certainly what is happening.
  421.  
  422. I see in another message that you say that you have turned on range-checking,
  423. well do it for the whole program not just parts of it.  Then check out any
  424. pointer use.  Dereferencing an unitialised pointer can cause the sort of
  425. problems you are
  426.  
  427. having so carefully check EVERY instance of dereferencing a pointer where
  428. the dereference is on the left side of the := operator.
  429.  
  430. Finally, using the debugger, I would place a watch on ExitProc to be absolutely
  431. sure that it is not changing in value before halting.  If it is, that will
  432. be your problem and you will then be faced with the task of tracking down
  433. what is doing
  434.  
  435. it.  If range checking is on that is unlikely though so I would bet on an
  436. unitialised pointer dereference.
  437.  
  438. TeeCee
  439.  
  440. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  441.  
  442.  
  443. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  444.  
  445. Conference 4
  446. Date       02-19-92 01:48:40
  447. From       Trevor Carlsen
  448. To         Kelly Small
  449. Subject    Menu Files
  450.  
  451.  TCID:66d992a4 59bf
  452. KS> Since the file definition wasn't included I did make the
  453. KS> assumption that the file was some type of fixed record format
  454. KS> and that multiple records would be read.  Can I plead late nite
  455. KS> posting????
  456.  
  457. No :-)  The file definition was included.  :-)
  458.  
  459. TeeCee
  460.  
  461. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  462.  
  463.  
  464. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  465.  
  466. Conference 4
  467. Date       02-19-92 01:59:20
  468. From       Trevor Carlsen
  469. To         Felix V.Leitner
  470. Subject    Your bug or mine?
  471.  
  472.  TCID:2b911591 59c0
  473. FV> Turbo Pascal's close(t) for var t : text; appends a ^Z character to
  474.  
  475. FV> the file, which is used to express EOF for DOS and many programs
  476. FV> supporting this ASCII convention. However, DOS will TYPE the file
  477. FV> correctly without ^Z, too.
  478.  
  479. TP does not append a ^Z to text files on closing.
  480.  
  481. TeeCee
  482.  
  483. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  484.  
  485.  
  486. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  487.  
  488. Conference 4
  489. Date       02-16-92 15:41:20
  490. From       Mark Ouellet
  491. To         Darren Lyon
  492. Subject    Mail adress, couldn't NetMail you!!
  493.  
  494.  Hi Darren,
  495.        Since I could not connect your system to send you
  496. the info I hope TeeCee won't mind too much.
  497.        BTW TeeCee, If you read this, I did receive your
  498. NetMail regarding my NetMail problems to zone 3 but rather
  499. than put you through the trouble of phoning me on your dime
  500. I've asked my Boss/Node some help regarding NetMailing
  501. through ZoneGates.
  502. Ok, back to you Darren, here is the message I was going to
  503. NetMail you:
  504. Hi Darren, As you asked, here is my Postal adress:
  505.        Mark Ouellet
  506.        1940 Sheppard St.
  507.        Quebec, Qc
  508.        Canada
  509.        G1S 1L2
  510.        Home Phone: (418) 527-6669 In case you ever need to
  511.        call, but be warned I'm rarely at home before 7 or
  512.        8 PM (Local time) on weekdays.
  513.        Oh BTW if it ever becomes more convenient for you,
  514.        you can allways send me FAXES at: (418) 646-1696,
  515.        that's the FAX at the office.
  516.                Best regards,
  517.                And thanks again.
  518.                Mark Ouellet.
  519. P.S. If you want to make sure Gerald replies, you'd better
  520. send him the same request. I don't know about Gerald but
  521. when I'm really in a hurry I usually reply to my private
  522. mail and skim the rest of the echo pausing only on messages
  523. which attract my attention, mostly code ;-)
  524. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  525.  
  526.  
  527. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  528.  
  529. Conference 4
  530. Date       02-16-92 15:56:40
  531. From       Mark Ouellet
  532. To         Ken Burrows
  533. Subject    Re: It works!
  534.  
  535.     On 11 Feb 92, you, Ken Burrows, of 1:249/201.21 wrote...
  536. KB> Your're quite welcome. That codes was untested by me, so you may have
  537. to
  538. KB> do a few fixes and optimization.
  539. I doubt if I'll have to change much to make it work. At
  540. first glance it seems perfect.
  541. KB> If you do manage to get TV's editor to work well, not just the number
  542.  
  543. KB> fix, but implementing all the standard editor features like wordwrap
  544. and
  545. KB> text import, let me know. I havn't had the time to mess with it, but
  546. I
  547. KB> could sure use a 'great' TV editor unit, as opposed to the 'very good'
  548.  
  549. KB> one that came with TP6.0.
  550. Will do Ken, the minute I get it out you'll be one of the
  551. first to know.
  552. KB> Programmers always see the bright side of being out of work. It frees
  553. us
  554. KB> up to pursue the kind of things we want to do.....
  555. Ken,
  556.        again, exacto-mundo but the way things are going,
  557. "I'm afraid they'll get an extension on my contract" ;-)
  558. Feels wierd to be talking that way but I might go full time
  559. into software. One of my friend allready requested me for a
  560. "Point Of Sale system", he sold one to a client but they are
  561. both pressuring me to drop everything and roll one out
  562. that's better than what they have. I wouldn't mind going
  563. into business with this friend, with his knowledge and his
  564. hard-ware sales allready going pretty well it could be a
  565. very interresting adventure. Of course I can live on a small
  566. salary without too much problem but the way his business is
  567. taking off, this could mean more "moula" than what I'm
  568. getting right now.
  569.        It wouldn't be hard considereing I'm doing a tech's
  570. job at a clerk's salary, that's what I get for not having my
  571. diploma. Being self-taught is not allways the best thing, at
  572. least not as a governement employee.
  573.        Best regards,
  574.        Mark Ouellet.
  575. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  576.  
  577.  
  578. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  579.  
  580. Conference 4
  581. Date       02-16-92 16:05:50
  582. From       Mark Ouellet
  583. To         John Gohde
  584. Subject    Re: What Diff
  585.  
  586.     On 12 Feb 92, you, John Gohde, of 1:264/212.0 wrote...
  587. JG> That  is  NOT  a  minor  point!  I  recently  tried  to  build my
  588. JG> modifications  to  Borland's  MicroStar   on  a  8088  with  640K
  589. JG> conventional memory ONLY.  It could not do it!  It needed to open
  590. JG> more files than it could handle (I  had files set to 60). The TPC
  591. JG> had no problems building it.  That program was only around 16-20K
  592. JG> and had about 25 units and 5 OBJ's.
  593.        It is a minor point if the application works on that
  594. configuration and all that's slowed down is compilation. You
  595. need the end user to be able to use it on a 8088 but should
  596. not expect the compiler to work as fast on it as on a 386 or
  597. 486.
  598.        When buidling furniture, you can do it with a hand
  599. saw or use industrial power-tools. The end user won't see a
  600. difference if you work well but you won't be able to output
  601. as many units as with power-tools.
  602.        So the real question should be if TP 6.0 can produce
  603. systems that run adequatly on those machines. If you are
  604. going to produce software as a business you should use what
  605. means are available to simplify your life and devellopement
  606. cycle.
  607.        TP 6.0 puts more tools at your disposal than
  608. previous versions did. You can't expect TP 6.0 to fit in 39k
  609. as TP 3.0 did nor expect it to perform as well on a 8088.
  610. JG> It seems  that 8 Megs might  me a requirement for  the TP6 IDE as
  611. JG> with ONLY  4 Megs, I  can hardly  do  anything on a  386SX. It is
  612. JG> constantly  running out  of memory  and forces  me to  unload and
  613. JG> reload just to release memory.
  614.        This is definetly not normal. What memory managers
  615. are you using, what setup. I used TP 6.0 on my 286 with
  616. 4Megs and never experienced any problem and I did have 1.5
  617. to 2 megs of RAM dedicated to a Disk-Cache at that time so
  618. that left only 2 Megs for TP.
  619.        Going back to the analogy with the power-tools, if
  620. they are not setup right or if you use them inadequatly, you
  621. won't be more productive.
  622.        That is why I spent a lot of time optimizing my 286
  623. system, making sure it was running as fast as it could and I
  624. did acheive it to the point where I would actually enjoy
  625. leaving my 386 at the office and going back to my 286. I
  626. even found it to be faster than the 386 system at times but
  627. on a general basis, just as fast.
  628. JG> That says to me, that Borland either goofed or just wrote off the
  629. JG> low  low end  user, which  is exactly  where most  starting hobby
  630. JG> programmers  would  start.  Seems  to  me  that there was another
  631. JG> message  that commented  on new  programmers starting  out with a
  632. JG> $4,000 super system ... And, it begs the question why someone who
  633. JG> could afford a $4,000 computer would prefer to use the IDE rather
  634. JG> than a $300 programmer's editor.  It seems reasonable to me, that
  635. JG> a freebee  IDE  would  mainly  be   of  interest  to  a  low  end
  636. JG> programmer.
  637.        Well again, why are woodworkers often keeping their
  638. old, allmost warn out chisels when they could easily get new
  639. ones for alot less money than they paid at first. BTW those
  640. systems are not that hard to come buy right now, in fact
  641. localy bought PCs used to cost a lot more than the
  642. equivalent US bought system where just this week my friend
  643. cut a deal with two of my co-workers for a 486 system:
  644.        ASUS 486-33 (accepts 32 Meg on M.B. 32 on 32 bit card)
  645.        4 Meg Ram (60ns SIMMS)
  646.        128k 20ns RAM cache (Exp. to 256k)
  647.        105 Meg Quantum HD 17ms access time
  648.        Mini-Tower case with 200W Pwr Sply.
  649.        2 Floppys, their choice of 3.5 or 5.25
  650.        VGA Wonder XL with 1Meg on it
  651.        Super Vga Color Monitor
  652.        2 Serial, 1 Parallel, 2 Floppies, 2 HDs
  653.        KeyBoard (101 key)
  654.        2500 $Cdn
  655.        Add $25 for a Conner 120 Meg HD instead of 105 Meg
  656. Hell, thats less money than I paid for my 286 three years
  657. ago. Allthough at that time I paid $550 for 1Meg ram ;-)
  658. that system came with 40Meg HD, 2Meg ram, Mono card and
  659. monitor.
  660. JG> And, by the  way: there is nothing wrong  with either my attitude
  661. JG> or logic!
  662. John,
  663.        With your attitude maybe not, with your logic
  664. well..., maybe you are forgetting some important point and
  665. that's what is getting you to the same answer each time.
  666.        You see I didn't have problems with my 286 but I did
  667. have to get an Intel Above Board 8 Plus as my original board
  668. only supported EMS 3.2, not the TRUE LIM 4.0 standard which
  669. the Intel brought to the system.
  670.        That is why I can't understand why you're having so
  671. poor results with TP 6.0's IDE and that is why I keep
  672. insisting something must be wrong somewhere in your setup.
  673. It should work, it won't work as it would on a 486 but it
  674. should work reliably none the less.
  675.        I wouldn't say Borland has written-off the low end
  676. users, if they had, TP 6.0 would not even load on a 286 let
  677. alone a 8088. They compromised so that 8088 users could
  678. still use it instead of giving us 386 & up users, even more
  679. power.
  680.        Best regards,
  681.        Mark Ouellet.
  682. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  683.  
  684.  
  685. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  686.  
  687. Conference 4
  688. Date       02-16-92 16:43:10
  689. From       Mark Ouellet
  690. To         Brad Roberts
  691. Subject    Re: Swapping on EXEC...
  692.  
  693.     On 10 Feb 92, you, Brad Roberts, of 1:382/52.0 wrote...
  694. BR>
  695. BR> Does anyone have any code to swap to EMS/DISK on EXEC?
  696. BR>
  697. BR> I've heard that the Turbo Power stuff has that, but I hate to shell
  698. out
  699. BR> that much money for this one routine.
  700. Brad,
  701.        Get Ralph Brown's SPAWNO40, it swaps to EMS, XMS,
  702. DISK and leaves only 384 bytes in memory during the swap.
  703.        Best regards,
  704.        Mark Ouellet.
  705. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  706.  
  707.  
  708. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  709.  
  710. Conference 4
  711. Date       02-16-92 17:10:20
  712. From       Mark Ouellet
  713. To         Jeff Mitchell
  714. Subject    Re: Physics / pascal
  715.  
  716.     On 11 Feb 92, you, Jeff Mitchell, of 1:229/422.0 wrote...
  717. JM> Where in Canada or the US can I Freq "Scorched Earth"? With a name
  718. JM> like that, it _must_ be good. Anyone know for sure whether it was
  719. JM> written in TP, TC, C++, etc, and if the source is available? If its
  720. JM> by some hacker group, chances are its in assembly, I'd think.. or
  721. JM> is TP actually fast enough to do any decent complicated graphics
  722. JM> with?
  723. Jeff,
  724.        if it's the same one I saw then it's not even worth
  725. the LD cost.
  726.        Best regards,
  727.        Mark Ouellet.
  728. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  729.  
  730.  
  731. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  732.  
  733. Conference 4
  734. Date       02-19-92 19:59:20
  735. From       Mark Ouellet
  736. To         Kelly Small
  737. Subject    Re: Turbo Pascal 3.0
  738.  
  739.     On 12 Feb 92, you, Kelly Small, of 1:114/33.0 wrote...
  740. KS> Well I don't know if they still include "upgrade.exe" with TP.
  741. KS> I used it to go from 3.0 to 4.0 and it will walk you through
  742. KS> alot of the changes needed.  IF you have 6.0 installed see if
  743. KS> it's in the util directory(I don't have TP on this PC or I'd
  744. KS> look).  I you have alot of inline stuff, you're in for alot of
  745. KS> rewriting, upgrade doesn't help you with inline stuff.  You
  746. KS> might look around for a TP version 4.0-5.5 which does have
  747. KS> upgrade.exe and use that.  The changes between these version
  748. KS> are minor to 6.0.
  749. Kelly,
  750.        Borland made the 5.5 Upgrade program available to
  751. 6.0 users on their BBS. Sorry don't have the number handy,
  752. don't know either if the file is still there.
  753.        Best regards,
  754.        Mark Ouellet.
  755. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  756.  
  757.  
  758. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  759.  
  760. Conference 4
  761. Date       02-18-92 21:33:40
  762. From       Wilbert Van.leijen
  763. To         Brad Roberts
  764. Subject    Re: Execute With Swap
  765.  
  766.  >> My version of EXECSWAP works fine with TP 6.0.
  767. >> Drop me a line if you're interested.
  768. [...]
  769. > But I'd like to take a look regardless..
  770. Drop me a line via netmail stating your post address, then...
  771. Regards,
  772. Wilbert
  773. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  774.  
  775.  
  776. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  777.  
  778. Conference 4
  779. Date       02-18-92 21:41:40
  780. From       Wilbert Van.leijen
  781. To         Kevin Higgins
  782. Subject    Completely Stumped!
  783.  
  784.  > Can anyone explain to me what I could possibly be doing wrong in a program
  785. > where a Halt(0) statement locks up the system completely? The program
  786. > seems to exit, but I'm never returned to a DOS prompt.
  787. [...]
  788. > Whether in DV or not, a cold boot is the
  789. > only thing that will give me the machine back!
  790. Suggest to check your chain of exit procedures.  Did you restore the pointer
  791. to the previous exit handler?
  792. Regards,
  793. Wilbert
  794. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  795.  
  796.  
  797. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  798.  
  799. Conference 4
  800. Date       02-18-92 21:48:30
  801. From       Wilbert Van.leijen
  802. To         Vince Laurent
  803. Subject    Re: More Vga tricks...
  804.  
  805.  > Got the tool box! Thanks! Now to find some loose Gilders...oh, and
  806. > BTW, could you would you please add English docs? There are people
  807. > here who would translate but my yearly wage does not allow me such
  808. > extras....
  809. Vince, since I'm not asking for money for the little projects I wrote on
  810. the disk I sent you: if you like VGAUNIT, send your loose guilders to the
  811. AUTHOR of the VGAUNIT package and beg him to supply some documentation in
  812. English.  It *is* a
  813. nifty collection of zooming fast graphic routines, don't you agree? If you
  814. agree, register this little gem. And if you want the docs in English: Money
  815. provides an incentive, I was taught in undergraduate economics.
  816. Regards,
  817. Wilbert
  818. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  819.  
  820.  
  821. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  822.  
  823. Conference 4
  824. Date       02-18-92 21:58:40
  825. From       Wilbert Van.leijen
  826. To         Joy Mukherjee
  827. Subject    Execute With swap
  828.  
  829.  > Is it short enough to be posted in a few messages??  I'd really be
  830. > interested in it.  I have a heck of a time getting things here in the
  831. > states though.
  832. Uh, I doubt it: 500 lines of 'pure' ASM (EXECSWAP.ASM), plus 300 lines in
  833. 1 unit (EXECSWAP.PAS)... Besides, I'm a little reluctant to publish it here:
  834. it's merely an *enhancement* of a routine written by the guys from TurboPower,
  835. not an original idea from me.  But it works like a charm, so if you're interesteleave me your address.
  836. > Did you ever release ZIP2OBJ?
  837. Yup, 3 November 1991.  ZIP2OBJ.ZIP, 42 kB, 2:500/31, 2:500/123.
  838. Regards,
  839. Wilbert
  840. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  841.  
  842.  
  843. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  844.  
  845. Conference 4
  846. Date       02-18-92 22:12:00
  847. From       Wilbert Van.leijen
  848. To         Trevor Carlsen
  849. Subject    Hello
  850.  
  851.  > The TP6 IDE is
  852. > *vastly* superior to the TP5.x IDE in almost every way you can think of
  853. -
  854. > multiple file editing, cut and paste between files, individual files to
  855. 1
  856. > meg, much better and more powerful debugger etc. etc.  However it IS a
  857. > memory hog. However as almost no professional and/or heavy duty programmer
  858. > would even consider using the IDE, this factor is usually not a
  859. > consideration for them.
  860. They would not even consider using the TP 6 IDE!
  861. My Gawd, what do those Pro's and HD-programmers want from an editor?
  862. Seems I'm doing my job behind a 036-keypuncher, so to speak.
  863. Heaven knows what I'm missing...
  864. Regards,
  865. Wilbert
  866. * Not Infatuated With The IDE, But It Stares Him In The Eye 8 Hours A Day
  867. *
  868. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  869.  
  870.  
  871. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  872.  
  873. Conference 4
  874. Date       02-18-92 22:18:40
  875. From       Wilbert Van.leijen
  876. To         Craig Hill
  877. Subject    help please
  878.  
  879.  > I  was wondering if anyone knew how do intercept (maybe) the
  880. > ALT-CTRL-DELETE function?  I am proficient at using ASM, and pascal.
  881. Here's an INT 9 handler doing just that.  Don't forget to restore the INT
  882. 9 vector to its previous owner before exiting your application!
  883. Procedure GetCtrlAltDel; Interrupt; Assembler;
  884. Const
  885.  Del          = $53;                  { Del make code }
  886.  Ctrl         = 4;                    { Ctrl bit mask in keyboard flag byte
  887. }
  888.  Alt          = 8;                    { Alt bit mask in keyboard flag byte
  889. }
  890.  KbdPort      = $60;                  { Keyboard port }
  891.  KbdCtrlPort  = $61;                  { Keyboard control port }
  892.  PIC          = $20;                  { 8259 Interrupt controller }
  893.  EOI          = $20;                  { End-of-interrupt }
  894. ASM
  895.        STI
  896.        IN     AL, KbdPort
  897.        AND    AL, 01111111b
  898.        CMP    AL, Del
  899.        JNE    @1
  900.        MOV    AH, 2
  901.        INT    16h
  902.        CMP    AL, Ctrl+Alt
  903.        JNE    @1
  904.    { If we come here, Ctrl-Alt-Del was pressed.  In this example, we
  905.      simply ignore it.  You might include a CALL to your special
  906.      Ctrl-Alt-Del handler here.  }
  907.        IN     AL, KbdCtrlPort
  908.        MOV    AH, AL
  909.        OR     AL, 10000000b
  910.        OUT    KbdCtrlPort, AL
  911.        XCHG   AH, AL
  912.        OUT    KbdCtrlPort, AL
  913.        CLI
  914.        MOV    AL, EOI
  915.        OUT    PIC, AL
  916.        JMP    @2
  917. @1:     PUSHF
  918.        CALL   DWord Ptr [SavedInt9]
  919. @2:
  920. end;
  921. Regards,
  922. Wilbert
  923. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  924.  
  925.  
  926. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  927.  
  928. Conference 4
  929. Date       02-18-92 22:34:20
  930. From       Wilbert Van.leijen
  931. To         Gerald Gutierrez
  932. Subject    VGA programing...
  933.  
  934.  > Something you MIGHT want to try.. but it does absolutely no overlap
  935. > checking, so make sure that whatever you are moving doesn't overlap (
  936. can
  937. > change the direction by which the move goes -- but I haven't included
  938. that
  939. > ).
  940. >
  941. > Procedure Move (SourcePtr,DestPtr:pointer; Size:word); Assembler;
  942. >
  943. >   ASM
  944. >     PUSH DS
  945. >     LES DI,DestPtr
  946. >     LDS SI,SourcePtr
  947. >     mov CX,Size
  948. >     cld
  949.            SHR  CX, 1
  950.            JAE  @1
  951.            MOVSB
  952.      @1:   REP  MOVSW
  953. >     POP DS
  954. >   End;
  955. Gerald, I couldn't resist optimising your code.  Now it will run up to 50%
  956. percent faster!
  957. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  958.  
  959.  
  960. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  961.  
  962. Conference 4
  963. Date       02-18-92 22:46:10
  964. From       Wilbert Van.leijen
  965. To         Chris Whitney
  966. Subject    TP6 is screwy! HELP!!
  967.  
  968.  >   HELP!!  Turbo Pascal 6.0 is screwed up!  It keeps changing variables
  969. > to large negative numbers for no reason!  It happens only once and a
  970. > while being played, but when it does it really messes things up!
  971. Huh?  I have no idea what you're talking about...  Cannot remember that I
  972. send you an early beta of my TP 6.0 RTL.
  973. Regards,
  974. Wilbert
  975. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  976.  
  977.  
  978. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  979.  
  980. Conference 4
  981. Date       02-19-92 20:30:10
  982. From       Wilbert Van.leijen
  983. To         Gerald Gutierrez
  984. Subject    Graphics
  985.  
  986.  > Oh really. Might I only say that the code was only typed out on the dot
  987. as
  988. > I don't spend my entire day facing the computer working out wonderful
  989. > little optimization methods for simple routines. If I didn't note that
  990. it
  991. > was only a routine of 'half decent speed', gee, I wouldn't really know
  992. > what I would do.
  993. Well, I was under the impression you were more or less uh, a terminal-junkie.
  994. Pardon the expression. <Insert smiley here> (Damn, where did I leave my text-modclipart-library?)
  995. Where else does this flood of messages come from?
  996. > Ho Humo... my, I seem to sense just a bit of immaturity in carrying on
  997. > anger. Could it be that of one who has claimed himself to be of a prof
  998. > programmer and proud of it ? NAHHH...........
  999. Um, no, only a Hard Reset will clear my HB (humour bit).
  1000. BTW - Here's the answer to your homework assignment:
  1001. Procedure PutPixel(x, y : Integer; color : Byte); Assembler;
  1002. ASM
  1003.        MOV    AX, y            { AX := y shl 8 ==> 256*y }
  1004.        XCHG   AH, AL
  1005.        MOV    DI, x            { DI := 256*y+x }
  1006.        ADD    DI, AX
  1007. {$IFOPT G+ }
  1008.        SHR    AX, 2
  1009. {$ELSE }
  1010.        SHR    AX, 1            { AX := 64*y }
  1011.        SHR    AX, 1
  1012. {$ENDIF }
  1013.        ADD    DI, AX           { DI := (256+64)*y+x }
  1014.        MOV    AX, 0A000h
  1015.        MOV    ES, AX
  1016.        MOV    AL, Color
  1017.        STOSB
  1018. end;  { PutPixel }
  1019. You're hereby invited to write the accompanying 'GetPixel'-function.
  1020. Dare to take up this challenge? If you do, it'll clear my AB (Arrogance Bit).
  1021. Cheerio,
  1022. Wilbert
  1023. * Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
  1024.  
  1025.  
  1026. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1027.  
  1028. Conference 4
  1029. Date       02-20-92 03:41:50
  1030. From       Trevor Carlsen
  1031. To         Mike Copeland
  1032. Subject    help w/search
  1033.  
  1034.  TCID:afa15609 5a1a
  1035. MC>    And it appeared to me that the original post was for that "simple
  1036.  
  1037. MC> usage", too. (Another mistake...) The problem of working with text
  1038. MC> files of very long (>255 character) records is different, as you
  1039. MC> state, and requires more than just a simple answer here - am I wrong?
  1040.  
  1041. MC> I mean, once such a record is found, using/displaying it is a
  1042. MC> non-trivial task - considering having to deal with deblocking over
  1043. MC> self-controlled buffers, and all that. At least, that's how such a
  1044. MC> problem seems to me, and if there's a _simple_ way to do it, I'd
  1045. MC> appreciate learning how.
  1046.  
  1047. var
  1048.  st     : string
  1049.  len    : byte absolute st;
  1050.  
  1051.  while not eof(f) do begin
  1052.    len := 0;
  1053.    while not eoln(f) and (len < 255) do begin
  1054.      inc(len);
  1055.      read(st[len])
  1056.    end;
  1057.    if eoln(f) then
  1058.      readln(f);
  1059.  end;
  1060.  
  1061. Obviously if a larger text buffer is set when f is opened it will be much
  1062. quicker. I find virtually no benefit from a buffer bigger than 2K so use
  1063. that as my default.
  1064.  
  1065. TeeCee
  1066.  
  1067. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1068.  
  1069.  
  1070. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1071.  
  1072. Conference 4
  1073. Date       02-20-92 03:53:00
  1074. From       Trevor Carlsen
  1075. To         Joe Mezzanini
  1076. Subject    PRINTER PORTS
  1077.  
  1078.  TCID:5027a623 5a1b
  1079. JM> How does one code a program print to lpt2 instead of lpt1  ..
  1080. JM> harder yet, how would I offer a choice of lpt1 or lpt2 and
  1081. JM> even worse ... how do I check if the selected port really has a
  1082. JM> printer on it and it is on line.
  1083.  
  1084. Here is a handy little unit that you can use.  I have removed the printer
  1085. unit that came with TP from the TURBO.TPL file and replaced it with this
  1086. one.  The test for a printer being ready is not guaranteed to be infallible.
  1087. Once this printer
  1088. has replaced the standard printer unit you will have to always specify what
  1089. printer you wish to use thus -
  1090.  
  1091.  writeln(Lst[n],...);  where n is your printer number.
  1092.  
  1093. unit printer;
  1094. {$D-,I-,S-}
  1095. interface
  1096.  
  1097. uses dos;
  1098.  
  1099. const
  1100.  PrinterNumb : byte = 0;
  1101.  
  1102. var
  1103.  Lst        : array[1..2] of text;
  1104.  
  1105. function PrinterStatus(p: byte): byte;
  1106. function PrinterReady(var b : byte; p: byte): boolean;
  1107.  
  1108. implementation
  1109.  
  1110. procedure RawMode(var L);       { make sure that device is in raw mode }
  1111.  var
  1112.    regs : registers;
  1113.  begin
  1114.    with regs do begin
  1115.      bx   := TextRec(L).Handle;         { place the file handle in bx }
  1116.      ax   := $4400;           { setup for function $44 sub-function 0 }
  1117.      MSDos(regs);                              { execute dos function }
  1118.      dl   := dl or $20;                            { bit 5 = raw mode }
  1119.      dh   := 0;                                      { set dh to zero }
  1120.      ax   := $4401;           { setup for function $44 sub-function 1 }
  1121.      MSDos(regs)                               { execute dos function }
  1122.    end; { with }
  1123.  end; { RawMode }
  1124.  
  1125. function PrinterStatus(p: byte): byte;
  1126.   { Returns the printer status. LPT1=p=1, LPT2=p=2 }
  1127.   var regs   : registers; { from the dos unit                         }
  1128.   begin
  1129.     with regs do begin
  1130.       dx := p - 1;        { The printer number                        }
  1131.       ax := $0200;        { The function code for service wanted      }
  1132.       intr($17,regs);     { $17= ROM bios int to return printer status}
  1133.       PrinterStatus := ah;{ Bit 0 set = timed out                     }
  1134.     end;                  {     1     = unused                        }
  1135.   end;                    {     2     = unused                        }
  1136.                           {     3     = I/O error                     }
  1137.                           {     4     = printer selected              }
  1138.                           {     5     = out of paper                  }
  1139.                           {     6     = acknowledge                   }
  1140.                           {     7     = printer not busy              }
  1141.  
  1142. function PrinterReady(var b : byte; p: byte): boolean;
  1143.  begin
  1144.    b := PrinterStatus(p);
  1145.    PrinterReady := (b = $90)         { This may vary between printers }
  1146.  end;
  1147.  
  1148. begin
  1149.  assign(Lst[1],'LPT1');
  1150.  rewrite(Lst[1]);
  1151.  RawMode(Lst[1]);
  1152.  assign(Lst[2],'LPT2');
  1153.  rewrite(Lst[2]);
  1154.  RawMode(Lst[2]);
  1155. end.
  1156.  
  1157. TeeCee
  1158.  
  1159.  
  1160. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1161.  
  1162.  
  1163. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1164.  
  1165. Conference 4
  1166. Date       02-20-92 04:57:10
  1167. From       Trevor Carlsen
  1168. To         Mike Hindle
  1169. Subject    Re: Variable number of parameters
  1170.  
  1171.  TCID:29f4ff54 5a1c
  1172. MH> Taking this one step further, I would like a routine capable
  1173. MH> of buffering output. Ie: a Write procedure allowing cursor
  1174. MH> positioning keeping the output in a buffer until a Writeln
  1175. MH> is used. Two benefits: Compact code and elimination of
  1176. MH> padding strings or using Spaces(# - Length(var)) or similar
  1177.  
  1178. This is simple to do using a text file device driver (TFDD).  Here's a unit
  1179. that will do that.  So if you want a formatted string just include this unit
  1180. in your uses declaration and -
  1181.  
  1182.  OpenFStr(f); { f must be declared as type text }
  1183.  write(f,'This will be formatted',r:8:2);
  1184.  FormattedStr := GetFStr(f);
  1185.  
  1186.  
  1187. unit filestr;
  1188.  
  1189. { Create a text file device driver to allow a formatted string }
  1190.  
  1191. interface
  1192.  
  1193. uses dos;
  1194.  
  1195. function GetFstr(var f: text): string;
  1196. procedure OpenFStr(var f: text);
  1197.  
  1198. {-----------------------------------------------------------------}
  1199. implementation
  1200.  
  1201. var
  1202.  FStrBuff     : string;
  1203.  
  1204. function GetFStr(var f: text): string;
  1205.  begin
  1206.    GetFStr     := FStrBuff;
  1207.    FStrBuff[0] := #0;
  1208.    TextRec(f).BufPos := 0;
  1209.  end; { GetFStr }
  1210.  
  1211. {$F+}
  1212. function FStrOpen(var f: TextRec):word;
  1213.  { This does nothing except return zero to indicate success }
  1214.  begin
  1215.    FStrOpen := 0;
  1216.  end; { FStrOpen }
  1217.  
  1218. function FStrInOut(var f: TextRec):word;
  1219.  begin
  1220.    FStrBuff[0] := chr(F.BufPos);
  1221.    FStrInOut   := 0;
  1222.  end; { FStrInOut }
  1223.  
  1224. {$F-}
  1225.  
  1226. procedure OpenFStr(var f: text);
  1227.  begin
  1228.    with TextRec(f) do begin
  1229.      mode      := fmClosed;
  1230.      BufSize   := Sizeof(buffer);
  1231.      OpenFunc  := @FStrOpen;
  1232.      InOutFunc := @FStrInOut;
  1233.      FlushFunc := @FStrInOut;
  1234.      CloseFunc := @FStrOpen; { no need for special close function }
  1235.      BufPos    := 0;
  1236.      BufEnd    := 0;
  1237.      BufPtr    := @FStrBuff[1];
  1238.      Name[0]   := #0;
  1239.    end; { with }
  1240.    FStrBuff[0] := #0;
  1241.    rewrite(f);
  1242.  end;  { OpenFStr }
  1243.  
  1244. end. { FileStr }
  1245.  
  1246. TeeCee
  1247.  
  1248.  
  1249. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1250.  
  1251.  
  1252. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1253.  
  1254. Conference 4
  1255. Date       02-20-92 04:12:00
  1256. From       Trevor Carlsen
  1257. To         Todd Zabel
  1258. Subject    Finding a file
  1259.  
  1260.  TCID:f1821a3a 5a1d
  1261. TZ> I am fairly new to TP and would like to develope a procedure that will
  1262.  
  1263. TZ> scan an entire drive for a file (something like NU Find File).
  1264. TZ> I am using TP ver 5.5.  Any help would be appreciated.  Thanks!
  1265.  
  1266. Here is a procedure that will check every file on a drive.  Modify it to
  1267. suit your needs for finding a particular file.
  1268.  
  1269. procedure Files(f : string);
  1270.  
  1271.  { Recursively search for and display all files below dir in the
  1272.    }
  1273.  { directory tree. The last character of dir must always be a backslash.
  1274.   }
  1275.  
  1276.  var
  1277.    SRec : SearchRec;                                    { from the dos unit
  1278. }
  1279.  
  1280.  begin
  1281.    writeln(f);
  1282.    FindFirst(dir + '*.*',AnyFile,SRec);
  1283.    while DosError = 0 do begin          { <>0 = no more matches to template
  1284. }
  1285.      with SRec do
  1286.        if (attr and directory = directory) and (name[1] <> '.') then
  1287.          Files(dir + name + '\')
  1288.        else
  1289.          writeln(name);
  1290.      FindNext(SRec);
  1291.    end;   { while }
  1292.  end; { files }
  1293.  
  1294. Untested.
  1295.  
  1296. TeeCee
  1297.  
  1298.  
  1299. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1300.  
  1301.  
  1302. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1303.  
  1304. Conference 4
  1305. Date       02-20-92 04:19:40
  1306. From       Trevor Carlsen
  1307. To         Mitch Davis
  1308. Subject    INTR VERSUS BASM
  1309.  
  1310.  TCID:533e6a41 5a1e
  1311. MD> Bzzzzt!  I DON'T have the RTL, and I can prove that invoking the
  1312. MD> DOS.INTR procedure does NOT lead to the INT opcode being executed.
  1313.  
  1314. You've saved me the trouble of posting a retraction!  I discovered that I
  1315. was not looking at INTR.ASM as I had thought I was!  I was looking at another
  1316. file That had a liberal sprinkling of ints.  So to John Richardson - sorry.
  1317.  
  1318. TeeCee
  1319.  
  1320. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1321.  
  1322.  
  1323. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1324.  
  1325. Conference 4
  1326. Date       02-20-92 19:09:00
  1327. From       Trevor Carlsen
  1328. To         Mitch Davis
  1329. Subject    Re: Converting Strings to UpperCase
  1330.  
  1331.  TCID:9017014d 5a23
  1332. MD> Trevor! <fx: reproving tone!..>
  1333.  
  1334. MD> While I agree that occasionally a GOTO makes things fit
  1335. MD> nice-and-Kentucky, this is not one of them.
  1336.  
  1337. Ok... on this one we will agree to disagree.  The method I showed fulfilled
  1338. all of the requirements I need before I will use one. Speed, code compactness
  1339. and readability...IMHO it wins on all three counts in this case therefore...
  1340.  
  1341. However I will make one concession!  In this example all three points together
  1342. add up to a very minor and insignificant total so I guess in the end it boils
  1343. down to just how badly you wish to avoid the dreadeds.
  1344.  
  1345. TeeCee
  1346.  
  1347. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1348.  
  1349.  
  1350. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1351.  
  1352. Conference 4
  1353. Date       02-21-92 08:50:20
  1354. From       Dj Murdoch
  1355. To         David G. Edwards
  1356. Subject    Re: TP 6.0
  1357.  
  1358.  DG> I'd go with TP 6.0.
  1359. I would have last spring, but remember Borland's release history:  4.0, 5.0,
  1360. 5.5 and 6.0 came out in the fall of successive years.  TPW 1.0 came out in
  1361. early 91, but there was no release in fall 91.  I'd take this to mean that
  1362. a new release
  1363. will certainly come out this year, possibly before the summer.  If you upgrade
  1364. to 6.0 now, you'll probably be asked to pay full upgrade price again pretty
  1365. soon.  (Even if Borland discounts the upgrade fee, there are the costs of
  1366. installing and
  1367. learning two systems within a few months.)
  1368. I'd say it's better to wait.
  1369. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1370.  
  1371.  
  1372. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1373.  
  1374. Conference 4
  1375. Date       02-21-92 09:02:40
  1376. From       Dj Murdoch
  1377. To         Max Maischein
  1378. Subject    Re: INTR VERSUS BASM
  1379.  
  1380.  MM> I dug some time ago deep in the code of the RTL, and I
  1381. MM> found, that turbo does this with self modifying code. It
  1382. MM> generates an INT ( except if you use the MSDos-procedure,
  1383. MM> this is done with a jump ), but this instruction is
  1384. MM> patched just before execution.
  1385. I'm starting to suspect that there are two versions of the RTL around.  Mine
  1386. definitely does *not* do what you describe.   Tracing through the following
  1387. test program
  1388.  uses dos;
  1389.  var
  1390.    r : registers;
  1391.  begin
  1392.    r.ax := 3;
  1393.    intr($10,r);   { set video mode }
  1394.  end.
  1395. on my machine doesn't execute an INT $10 instruction.  Does it on yours?
  1396. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1397.  
  1398.  
  1399. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1400.  
  1401. Conference 4
  1402. Date       02-21-92 09:12:30
  1403. From       Dj Murdoch
  1404. To         Richard Nelson
  1405. Subject    Re: Stand alone Turbo Help
  1406.  
  1407.  > Could you suggest to the
  1408. > programming team that, being able to increment or decrement
  1409. > the heap space of a program during run-time would be nice. I
  1410. > know this one is a toughy but it would be great.
  1411. RN> There's a procedure in the Turbo Vision units that does
  1412. RN> just that, but the name of it escapes me at the moment.
  1413. RN> It's not tied to TV, actually, so you should be able to
  1414. RN> use it for anything.  It's something like SetMemTop.
  1415. SetMemTop is right, but you forgot it in the manual.  It's only documented
  1416. in the online help, as far as I can see.
  1417. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1418.  
  1419.  
  1420. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1421.  
  1422. Conference 4
  1423. Date       02-21-92 09:16:50
  1424. From       Dj Murdoch
  1425. To         Jud Mccranie
  1426. Subject    Re: Tp 6.0 Ide
  1427.  
  1428.  RP> My largest programs: How about Turbo Vision Applications? They
  1429. RP> tend to be very hefty, don't they? I even can compile the
  1430. RP> TVDEMO's with no apparent difficulties in the IDE.
  1431. JM> Probably, but I don't use TV.  But the fact that you can do what you
  1432. JM> do in the TP6 IDE indicates that they are much smaller than mine.
  1433. Or that he has better designed units with fewer interfaced symbols, or that
  1434. he has the IDE set up differently, or that he has fewer TSRs than you, or
  1435. possibly a million other things.  The IDE doesn't run out of memory at a
  1436. fixed number of lines
  1437. of source code.
  1438. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1439.  
  1440.  
  1441. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1442.  
  1443. Conference 4
  1444. Date       02-21-92 15:33:10
  1445. From       Trevor Carlsen
  1446. To         Alex Boisvert
  1447. Subject    Creating a text editor.
  1448.  
  1449.  TCID:78832b3d 5a65
  1450. TC> In fact a direct quote from the documentation - "..., the
  1451. TC> TextEditor provides a host of new editing commands, and the
  1452. TC> result is a plug-and-play editor comparable in power to the Turbo
  1453. TC> Pascal editor."
  1454.  
  1455. AB> Except for one MAJOR drawback...  It cannot edit files larger
  1456. AB> than 64k, which is an understandable limitation.
  1457.  
  1458. I have not used it, so will accept that as fact.  However full source code
  1459. is supplied, so it should not be too big a job to eliminate that drawback.
  1460.  
  1461. TeeCee
  1462.  
  1463. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1464.  
  1465.  
  1466. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1467.  
  1468. Conference 4
  1469. Date       02-21-92 18:38:50
  1470. From       Trevor Carlsen
  1471. To         CHRISTOPHER KODANI
  1472. Subject    Thanks
  1473.  
  1474.  TCID:5781cb3f 5a66
  1475. CK> I've got another question. One of my engineer friends says that PASCAL
  1476. CK> is becoming sort of out of style. He says that a lot more people are
  1477. CK> learning to program in C now. Is C a more advanced language? Are there
  1478. CK> any benefits that TP has over C?  Vice versa?  One thing that I've
  1479. CK> noticed after looking at some C code is that it looks rather cryptic
  1480.  
  1481.  
  1482. There is no doubt that being fluent in C will stand you in better stead when
  1483. job hunting time comes around.  There are very few software houses that develop
  1484. large applications in Pascal but that is not to say they couldn't if they
  1485. wanted to.
  1486.  
  1487.  
  1488. The reason they do not, is basically because C is a very powerful, reasonably
  1489. portable and flexible language which was around long before Turbo Pascal.
  1490. Until Turbo Pascal came along and gave new meaning to the language, Pascal
  1491. had a lot of
  1492. serious limitations as a commercial language.  This reputation stuck and
  1493. even today you will find professional programmers who say that C is faster
  1494. and more powerful.  In actual fact the two languages are very closely matched
  1495. on both counts
  1496. and in many cases TP is the faster.  Portability is one area where Turbo
  1497. Pascal misses out though.
  1498.  
  1499. I recommend you become proficient in TP and then take up C.  You will learn
  1500. good programming practices (GPP) and find the transistion to C easier.
  1501.  
  1502. TeeCee
  1503.  
  1504. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1505.  
  1506.